[build] Fix libcurl and cross-compiling corelibs #82924
Conversation
finagolfin
requested review from
etcwilde,
justice-adams-apple and
shahmishal
as code owners
| # Adding this until we can configure these corelibs repos with a CMake | ||
| # toolchain file | ||
| SWIFT_TARGET_CMAKE_OPTIONS+=( | ||
| -DCMAKE_Swift_COMPILER_TARGET:STRING="${SWIFT_HOST_TRIPLE}" |
There was a problem hiding this comment.
Recent corelibs changes to use CMAKE_Swift_COMPILER_TARGET broke cross-compiling with build-script. This wasn't noticed on the CI because the only one that cross-compiles the whole toolchain, the macOS CI, doesn't build corelibs like libdispatch or Foundation. I've been working around this for months on my Android CI, finagolfin/swift-android-sdk@774f3b612, but this fixes it so I can remove those.
|
|
||
| self.generate_toolchain_file_for_darwin_or_linux(host_target) | ||
|
|
||
| if self.args.build_zlib: | ||
| # If we're building zlib, make cmake search in the built toolchain | ||
| toolchain_path = self.host_install_destdir(host_target) | ||
| self.cmake_options.define('CMAKE_FIND_ROOT_PATH', toolchain_path) | ||
| self.build_with_cmake(['libcurl'], self.args.curl_build_variant, []) | ||
| self.build_with_cmake(['libcurl.a'], self.args.curl_build_variant, []) |
There was a problem hiding this comment.
I'm trying out using the Android NDK's CMake toolchain file to build this and other repos, and found that this earlier libcurl target doesn't exist.
@etcwilde, these breaks suggest nobody is using these build scripts for Foundation dependencies that you added years ago: any plans to start using them more, say on linux? I'm looking into employing them in the upcoming official Android CI.
There was a problem hiding this comment.
I don't currently have plans to use this for Linux at the moment. I was going to use it for an Android build but ended up not using build-script at all.
Hmm, I could have sworn the libcurl target name existed. They create an alias library off of the "selected" library:
add_library(${LIB_NAME} ALIAS ${LIB_SELECTED})
add_library(${PROJECT_NAME}::${LIB_NAME} ALIAS ${LIB_SELECTED})Then there's a bit of logic to determine which is "selected":
...
set(LIB_STATIC "libcurl_static")
set(LIB_SHARED "libcurl_shared")
if(NOT BUILD_SHARED_LIBS AND NOT BUILD_STATIC_LIBS)
set(BUILD_STATIC_LIBS ON)
endif()
if(NOT BUILD_STATIC_CURL AND NOT BUILD_SHARED_LIBS)
set(BUILD_STATIC_CURL ON)
elseif(BUILD_STATIC_CURL AND NOT BUILD_STATIC_LIBS)
set(BUILD_STATIC_CURL OFF)
endif()
# Lib flavour selected for curl tool
if(BUILD_STATIC_CURL)
set(LIB_SELECTED_FOR_EXE ${LIB_STATIC})
else()
set(LIB_SELECTED_FOR_EXE ${LIB_SHARED})
endif()
# Lib flavour selected for example and test programs.
if(BUILD_SHARED_LIBS)
set(LIB_SELECTED ${LIB_SHARED})
else()
set(LIB_SELECTED ${LIB_STATIC})
endif()
...Edit: To be clear, I am also running into issues with running ninja libcurl, so you are right that it does not appear to work. ninja libcurl_static does work for me though.
Edit Edit: It doesn't work because alias libraries don't show up as phony targets in the generated build system. 🤦 Whoops.
There was a problem hiding this comment.
I don't have plans to use build-script, but I would recommend using libcurl_static rather than libcurl.a (or at least call it curl.lib which would be the windows name). This unnecessarily makes the handling platform specific otherwise.
There was a problem hiding this comment.
Thanks for the info, made the suggested target name change.
|
@swift-ci test |
|
@swift-ci smoke test |
|
@swift-ci smoke test windows |
@compnerd and @etcwilde, please take a look.